Generate Spring Security wiring through the beans DSL - #16119

What

Two changes to the spring-boot-starter-security forge feature.

1. Wire the security beans through the beans DSL

The feature generated a separate SecurityConfig class and pulled it into the generated app with @Import(SecurityConfig). This declares the same two beans through the beans DSL (#16019) on the generated Application class instead, and deletes the SecurityConfig template.

No dependency declaration is added to the generated build: grails-core already exports grails-beans-dsl as an api dependency, so the transform reaches any app that depends on grails-core.

Applications generated without the feature are unaffected — application.rocker.raw renders byte-identical output for them.

2. Lock down the generated defaults

The generated filter chain used anyRequest().permitAll(). That left the scaffolded user admin at /user/** open to anonymous visitors, and made an app generated with the security feature less restrictive than one generated with no security configuration at all, since Spring Boot's own default authenticates everything.

The new rules match the shape the Grails Spring Security feature already configures through staticRules, so the two security features no longer disagree about whether a generated app is open or closed. ROLE_ADMIN is what bootStrap.rocker.raw seeds.

Two deliberate departures from that feature's list: /shutdown is not permitted, and /**/js/**, /**/css/**, /**/images/** and /**/favicon.ico are left out because asset-pipeline serves all of them under /assets/**.

Result

A generated secured app, with no src/main/groovy/**/SecurityConfig.groovy:

@CompileStatic
@EnableWebSecurity
class Application extends GrailsAutoConfiguration {
    static void main(String[] args) {
        GrailsApp.run(Application, args)
    }

    def beans = {

        bean(PasswordEncoder) {
            PasswordEncoderFactories.createDelegatingPasswordEncoder()
        }

        bean('filterChain', SecurityFilterChain) { HttpSecurity http ->
            http
                .authorizeHttpRequests {
                    it.requestMatchers('/', '/index', '/index.gsp', '/error', '/assets/**').permitAll()
                      .requestMatchers('/user/**').hasRole('ADMIN')
                      .anyRequest().authenticated()
                }
                .formLogin { }
                .logout { it.logoutSuccessUrl('/') }
            http.build()
        }
    }
}

Also

user.rocker.raw marks the password field with the password constraint, so scaffolding renders it masked rather than as plain text:

password blank: false, password: true

Testing

SpringBootStarterSecuritySpec asserts the DSL in Application.groovy, that no SecurityConfig.groovy is generated, the new authorization rules, and the new constraint. The negative case asserts neither def beans = { nor @EnableWebSecurity appears without the feature.

• Full :grails-forge-core:test — 322 tests, 0 failures, 1 skipped

Rendered output was inspected directly for both the secured and unsecured variants.

Not covered here: the tests assert on generated text; no generated project was compiled and booted. That is worth a reviewer's attention on the second change in particular — a lockdown default can break a generated starter on first run in a way permitAll could not, if some path the welcome page needs is missing from the permit list.